fix: fix error in using relativeHeadRowIndex for writing tables only#810
fix: fix error in using relativeHeadRowIndex for writing tables only#81032154678925 wants to merge 11 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request fixes a bug where relativeHeadRowIndex() was being applied twice when writing data to tables with headers, causing extra blank rows to appear between the header and data. The fix changes the condition from checking whether the sheet is new to checking whether the current write holder (which could be a table) is new and has no head.
Changes:
- Modified logic in
ExcelWriteAddExecutor.add()to checkcurrentWriteHolderinstead ofwriteSheetHolderfor applying the row index offset - Added import for
AbstractWriteHolderclass - Added instanceof check before casting to
AbstractWriteHolder(unnecessary based on codebase architecture)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (currentWriteHolder instanceof AbstractWriteHolder) { | ||
| AbstractWriteHolder writeHolder = (AbstractWriteHolder) currentWriteHolder; | ||
| if (!writeHolder.getExcelWriteHeadProperty().hasHead()) { | ||
| newRowIndex += currentWriteHolder.relativeHeadRowIndex(); | ||
| } |
There was a problem hiding this comment.
The instanceof check for AbstractWriteHolder is unnecessary. All implementations of WriteHolder (WriteSheetHolder, WriteTableHolder, WriteWorkbookHolder) extend AbstractWriteHolder. The rest of the codebase directly casts currentWriteHolder() to AbstractWriteHolder without instanceof checks (see WriteHandlerUtils.java lines 79, 124, 160, 168, 176, 184). For consistency with the existing codebase patterns, the cast should be done directly without the instanceof check.
| if (currentWriteHolder instanceof AbstractWriteHolder) { | |
| AbstractWriteHolder writeHolder = (AbstractWriteHolder) currentWriteHolder; | |
| if (!writeHolder.getExcelWriteHeadProperty().hasHead()) { | |
| newRowIndex += currentWriteHolder.relativeHeadRowIndex(); | |
| } | |
| AbstractWriteHolder writeHolder = (AbstractWriteHolder) currentWriteHolder; | |
| if (!writeHolder.getExcelWriteHeadProperty().hasHead()) { | |
| newRowIndex += currentWriteHolder.relativeHeadRowIndex(); |
Signed-off-by: 苗泽楠 <anan_laolu@foxmail.com>
|
These tests contain no assertions and therefore do not validate the fix. Please enhance them with assertions that check the actual output. (Also ensure that both XLSX and XLS formats are covered) |
- Add read-back verification via WorkbookFactory for both test cases - Parameterize with @EnumSource to cover both .xls and .xlsx formats - Use randomized offsets (0–9) and data sizes (1–10) for broader coverage - Replace non-deterministic Random data with predictable prefix‑index pattern - Resolve header string from @ExcelProperty annotation via reflection to avoid coupling to a hardcoded value in WriteSheetData - Calculate expected sequential row layout (tables are sequential, not overlapping; B's position = A's last row + offsetB + 1) Signed-off-by: 苗泽楠 <anan_laolu@foxmail.com>
Signed-off-by: 苗泽楠 <anan_laolu@foxmail.com>
谢谢，我修改了测试代码，并且成功跑通测试，且测试了未修改bug的代码，测试是跑不同的。我的代码经验不多，还有什么需要修改的么？ Thank you. I modified the test code and successfully ran through the test. I also tested the code without modifying the bug. The test runs differently. I don't have much code experience. Is there anything I need to change? |
Purpose of the pull request
Closed: #794
When you do not write directly in the
sheet, but only write data in thetableand set thehead, the offset value set withrelativeHeadRowIndex()will make an error, and the blank line with the specified offset will be empty again between the head and the data. If theheadis not set, the offset value set withrelativeHeadRowIndex()will not take effectWhat's changed?
Change the judgment of whether to add offset in the
addmethod in theExcelWriteAddExecutorclass fromwriteSheetHoldertocurrentWriteHolderBefore:
After:
Checklist